guard() was incorrectly counting the depth when either of the
following was true:

- the error occured inside the first "start" event on which guard()
  is used: in that case, guard() would fail to swallow the
  corresponding "end" event.

- after an error, further elements appear in the stream before the
  guard()-ed element is over. in that case, guard() would fail to
  account for the "start" events caused by those events, and thus
  let its depth counter go entirely out-of-sync with the XML tree

If this flaw is combined with the use of a supressing
xso_error_handler, it is possible to make elements appear higher
up in the XML stream tree than they actually are; this implies
that it is possible to inject elements in the XML stream.

It requires very specific circumstances for an application to be
vulnerable. Example of a vulnerable XSO definition is:

class Baz(aioxmpp.xso.XSO):
    TAG = ("https://xmlns.zombofant.net/aioxmpp/test", "baz")

class Bar(aioxmpp.xso.XSO):
    TAG = ("https://xmlns.zombofant.net/aioxmpp/test", "bar")

    validated = aioxmpp.xso.Attr(
        "foo",
        type_=aioxmpp.xso.JID()
    )

    children = aioxmpp.xso.ChildList([Baz])

@aioxmpp.IQ.as_payload_class
class Foo(aioxmpp.xso.XSO):
    TAG = ("https://xmlns.zombofant.net/aioxmpp/test", "foo")

    child = aioxmpp.xso.Child([Bar])

    def xso_error_handler(self, descriptor, ev_args, exc_info):
        return True

If an attacker sends:

    <iq ... type='result'><foo xmlns='https://xmlns.zombofant.net/aioxmpp/test'><bar foo='&quot;@bar'><baz/><baz/><baz/></bar></foo></iq>

to an application, it will see the "end" event of the </iq> *on the
stream level*, breaking the XML stream (because it expects a
"start" event instead of an "end" event).

More sophisticated attacks could be used to make an element appear
on the stream level instead, which would open the possibility of
injecting, for example, <message> stanzas remotely into the stream
of a vulnerable aioxmpp client, with arbitrary sender.